交易履约之结算平台实践

Tech

导读

      京东科技业务在快速发展的同时，产生了众多线上化资金结算的需求。传统的线下资金结算模式有着人力成本高、耗时长、多方沟通协调成本高、结算准确率低等固有缺点，且无法满足“风法财审”对于资金流程的管控要求，在此背景下金道结算平台孕育而生。本文从系统建设的背景、设计细节、已支撑案例及适用业务场景多个层面进行详细阐述。读者可以关注文中所讲的系统实践过程，进而对结算领域系统设计能力提升，具有一定的参考价值。

01 概述

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！

1.1 背景

      业务在快速发展的同时，产生了众多线上化资金结算的需求。传统的线下资金结算模式有着人力成本高、耗时长、多方沟通协调成本高、结算准确率低等固有缺点，且无法满足“风法财审”对于资金流程的管控要求。金道结算平台应运而生，专注于内部中心化流量场外的、通过外部场或搭建撮合平台进行获客、转化的场景，支撑业务方面向客户、合作伙伴、经销商、供应商等多利益相关方，实现快速、专业、高效、准确的线上化计费结算解决方案提供和能力支持。金道结算平台对接各垂直业务系统，实时同步业务的交易数据，并经过标准的结算流程（数据标准化预处理，清分，计费，分摊，结算单生成、运营确认等），最终通过财务渠道或其他支付渠道完成资金结算，有效降低了各业务系统结算成本的投入，提升业务资金流转的健康度，为业务的快速增长赋能。

1.2 痛点

      业务系统在开展业务时，以当前线下处理的方式，普遍存在以下痛点：

计算难：计算规则复杂，数据量大，人工难以处理；

响应慢：现有业务变化快和新增业务速度快，人工效率较低，难以快速响应新资金结算模式；

风险高：人工计费、核对、结算数据风险高且不合规，难以溯源，操作风险高；

运营难：基础数据不完善，线下无法多维度分析，无法精准管理业务成本，及时调整策略；

成本大：人工结算的方式，投入的时间和资源成本高。

1.3 定位

     金道结算平台深耕业务场景，打通平台接口，支持跨平台结算，是业财一体化的桥梁，为平台型交易及全域营销赋能。

图1 平台定位

1.4 优势

      金道平台的建设，在解决业务痛点基础上，平台优势能够从准、快、好、省几个层面体现：

1. 计费准确：支持大数据量计费，准确性达99.99%；

2. 结算快速：灵活支持按日或月等维度结算，缩短结算账期，实现资金快速收付；

3. 运营精细：支持业务精细化运营，助力业务发展；

4. 成本降低：提高运营效率，节省成本。

02   系统架构介绍  

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。从设计稿出发，提升页面搭建效率，亟需解决的核心问题有：

2.1 名词解释

      

名词	解释
清分	清分是在清算前对数据标准化处理阶段。在本文中，清分指的是对交易明细数据的核对、识别、调整及打标操作。
清算	清算是标准化数据的计算及核对过程，本文清算主要完成标准化数据的核对、计费及分摊处理。
结算	结算是汇总账单，并完成资金最终转移的过程。本文中的结算指的是对清算明细数据，以不同的维度生成结算单并确认，最终通过财务系统完成收付款的整个过程。
计费	本文中指：单据数据按一定计算规则，生成的结果金额及过程金额。
分摊	本文中指：费用存在多个承担方，在清算过程中，会把计费的结果金额，再次按分摊的规则划分到各方。
累额	本文中指：累额服务于分摊动作,具体过程 为分摊规则中配置了每个承担方最大的承担上限，那么在计费后需要分摊时，需要参考承担方已累加金额是否到了上限，如果到了上限，则此方不进行分摊金额，否则正常累加本次金额。
冲正	本文中指：同一单据重新计费、分摊时，需要把此单据在原累加总额值减去，再累加上本次金额。
重置	本文中指：顺序清算场景时，业务线需要在历史的某个单据向后重新清算时，累额中需要把总额回退到此单据清算时累加的总额快照，并标识累额流水中哪些是效数据。

表1 名词解释

2.2 服务域设计

       

图2 服务域划分

     平台基于DDD思想，划分清分域、清算域、结算域及报表域四个大域，每个子域又依次划分了自己的子域。

2.3 整体架构图

  图3 整体架构图

说明：

1. 金道平台从数据处理流向上，自上而下划为分数据源、清分、清算、结算及下游，从使用群体上分为零售客户及科技客户。

2. 业务数据通过实时或离线两种方式接入平台。在清分中判别数据归属清分类型（通用流程或个性化流程），而进入不同的清分处理流程。清分域主要是按一定的规则对原始数据进行核对、识别、调整及打标动作，为清算做好数据标准化。

3. 当清分标准化数据后，会推送结果数据到清算域，清算按模型配置的清算规则，通过流程控制进入计费、分摊、累额等不同的组合处理（譬如：只计费、先计费后分摊、只分摊、先分摊后计费等），以及会补全结算户、合同及汇率数据，数据落到清算明细表。

4. 结算模型达到结算周期条件时，会产生一个结算任务。结算任务处理时，会从清算表中按条件获取待结算明细，然后按结算维度汇总，各自产生结算单信息。结算单自动按预定审批流程完成确认，最终推送到财务渠道（渠道当前有：科技财务、预存款账户、pop核算等），由财务渠道系统完成收付款。

2.4 典型问题技术设计

    

2.4.1 分片任务处理组件

      平台采用cds实现分库分表存储数据，通过DTS把数据同步到ES，并进行报表明细显示。在整个结算流程中，存在众多需要聚合表数据处理操作（譬如：单据预处理、清算预处理、生成结算单，条件拉取条件数据等），因为本平台是与资金结算相关，金额必须绝对准确，所以未采用ES作为可信的聚合处理源。在前期公司调研相关产品后，未找到基于分库分表有高效的聚合工具，所以特研发以下“分片任务处理组件”：

      图4 分片任务处理组件

      此组件提供抽象的类shardingTask,预定好3个核心动作：split(如何分片）、do(分片数据如何处理）、merge(最终数据如何聚合）。

      核心处理过程为：先统一抽象批量处理逻辑，把批量数据分片发送 MQ 并落库。多节点多线程进行消费，消费完成后，对数据库 MQ 记录的状态进行修改。每个分片处理完后，匀检查该任务下的消息是否全部处理完成，如果完成后，最后执行合并逻辑，那么此时我们想要的最终结果就出来了。

2.4.2 顺序清算

背景

      某些业务系统要求以业务发生的流水，按顺序做计算、分摊及累额，为了解决这个场景，特设计以下通用的处理流程。

实现过程

      第一步：数据接入在中间表中，按业务时间排序，然后打上唯一流水号（流水号自增特点）：

图5 打标流水号

      第二步：业务人员或系统自动处理单据，进行清算时，会触发条件 ，进入以下预清算处理流程：

图6 预清算处理流程

原理：

      不需要按顺序处理的单据数据，直接发送了待清算MQ主题 中，需要按顺序清算单据，进入主流程。

挑战：

1. 分片存储情况下业务数据明细百万级排序；

2. 顺序处理如何保证处理效率；

3. 顺序清算异常情况，如何断点继续处理。

实现核心点：

      原始快照表打标顺序流水号，利用分片任务组件，拉取数据后放在zset中进行排序，全部放入后，触发顺序清算流程。为应对大促销日，可以在业务能容忍的范围中，开放并发清算（并发数据之间不保证顺序），要成功整体成功，要失败整体失败。

2.4.3  累额重置

背景

      按顺序计费、分摊及累额场景，当业务人员需要回退到历史某个时间的单据重新顺序清算时，就需要从累额明细中重置到将要执行单据的位点（也就是累加的总额回退回去，并在流水中标识出哪些是无效数据）。

实现原理

图7 累额重置实现原理

03   系统功能介绍 

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。从设计稿出发，提升页面搭建效率，亟需解决的核心问题有：    

3.1 结算流程

图8 结算流程

整个流程主要分为 4 个步骤：

1. 出具结算方案：每当有新业务场景接入，需由产品同学调研业务运营同学以了解业务场景，并出具专业的线上化结算解决方案，辅助业务系统备齐结算所需数据来源，并辅助业务数据同学加工结算数据表。

2. 结算模型配置：依据结算解决方案，在金道结算系统完成结算模型的基本信息配置以及单据处理、清算处理、结算处理、下游处理等环节的规则配置。

3. 结算任务处理：业务交易发生推送到结算平台，然后经过清分流程处理、清算流程处理、结算单生成，如果有对账确认流程配置，则会推送账单由客户进行账单确认，发票暂由运营人员线下开具（后续会支持）。

4. 结算完成：等确认完账单后，账单会推送到财务进行收付款处理，财务的处理结算会通知到结算平台。最终账单信息可以由结算平台提供归档及检索。

3.2 主要配置

3.2.1结算模型

1. 基本信息

图9 基本信息

2. 规则信息

图10 规则信息

      结算模型是本平台核心配置，内容涵盖基本信息、结算周期、单据处理、清算处理、结算处理及下游配置，运营人员可以通过引导一站式配置好整个所需功能。

3.2.2 计费模型

1. 计费规则

图11 计费规则

      对外提供计费服务，支持不同产品的计费模型和计费规则，形成计费规则引擎，实现计费规则和模型的可配置化，可支持灵活多变的计费场景。

2.分摊规则

      图12 分摊规则

       本平台支持基于预算的分摊配置能力，适合成本分摊型结算。目前我们支持分摊方式有按比例、按顺序及按固定金额，支持两级分摊，具备了大部分业务应用场景支撑能力。

04   业务支持案例   

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

      目前金道结算平台已赋能了 微电佣金、白条息费成本、内容平台创作者佣金、支付营销券计收等 业务的线上化结算场景，日均处理订单量达5000万+，日均有效结算金额达1300万+，有力支撑了业务快速发展。

4.1 微电业务

合作案例：为微电业务解决职场、坐席销售金融产品而产生的资金结算问题，包括佣金、业绩考核、企微加粉费和电话使用费等。

业务场景：微电业务售卖的金条、白条、基金、养老保障、小金保、股票、延保、CPA等。

图13 微电业务

4.2 白条业务

合作案例：为白条与商城解决商城、科技、供应商、POP商家联合营销而产生的白条营销费用收取问题。

业务场景：收取商城、供应商、POP商家的白条营销费用。

图14 白条业务

4.3 支付业务

合作案例：为支付解决外部机构采购优惠券，而产生的支付营销费用收取问题.

业务场景：收取外部机构的支付营销费。

图15 支付业务

05   总结   

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

       针对目前业务场景、商业模式进行调研分析，主要有四种结算模式:分佣结算、业绩考核结算、技术服务结算及商品营销结算。

合作平台	产品	费用项	业务模式-分类	业务模式-内容
微电增长	金条	交易佣金 企微加粉 工资计算 返佣奖励 计时话费 计件凭证费	分佣结算	开展业务时，需要进行佣金结算（交易分佣、代理费用等）
白条	业绩考核结算	对个人进行考核，按工时、工作量考核进行结算
基金
股票
小金保
保险理财
延保
保险
开放平台	企业认证	套餐费用 逐笔费用 接入费用
OCR
区块链存证	技术服务结算	业务提供各类技术服务，需要对技术服务费用进行结算
商家中心	白条	白条息费 支付营销费 小贷营销费 积分减免
支付
小贷
积分	商品营销结算	商品进行营销，需要对营销费用进行结算

      4种模式覆盖目前所有场景，随着接入业务场景的扩展，模式可再增加。

推荐阅读KVC原理与数据筛选
测试角色在项目各阶段的项目管理tips
会员权益核心引擎ZCube原理与实践
数据驱动测试-从方法探研到最佳实践

求分享

求点赞

求在看